Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

Use ByVal

Use ByVal whenever possible. If a routine’s parameter is declared ByVal, any changes made by the routine do not return to the calling routine. This reduces the chances that the routine will make accidental changes that will effect the caller.

If changes to a parameter must be visible to the calling routine, the routine should declare the parameter ByRef. This emphasizes the fact that the parameter will be modified so the programmer writing the calling routine can easily see that changes will return to the calling routine.

Private Sub CallBoth()
Dim X As Integer    

    X = 0 
    ' X is now 0.    
    
    PassedByVal X
    ' X is still 0.    
    
    PassedByRef X
    ' X is now 2.
End Sub

' ByVal so changes do not return to the caller.
Private Sub PassedByVal(ByVal X as Integer)    
    X = 1
End Sub

' ByRef so changes return to the caller.
Private Sub PassedByRef(ByRef X as Integer)    
    X = 2
End Sub

If you change a parameter from ByVal to ByRef, carefully examine the code to see if the value is changed during the routine. If so, making the parameter ByRef will probably create bugs. You can avoid this by using a temporary variable in place of the original variable during calculations.

If you change a parameter from ByRef to ByVal, carefully examine all calling routines. If they expect the parameter’s value to change and it does not, the result is probably a bug.

Separate Debug and Nondebug Code

Nondebug code should not use debug variables, and vice versa. If these types of code share variables, the program may behave differently during runtime and design time. Variables that exist in the debugging environment may have different values or may not even exist in the final compiled program.

In the following code, the variable X is defined only when the DEBUG_MODE compiler constant is True. If the final version of the program sets DEBUG_MODE to False, Visual Basic will refuse to compile the program because X is undefined.

Private Sub MySub()
#If DEBUG_MODE Then    
    Dim X As Integer
#End If

Dim i As Integer    

    X = 1    
    For i = 1 To 10        
	X = X * i    
    Next i
End Sub

The following code is even trickier. When DEBUG_MODE is False, the subroutine does not create a local variable named X. Because there is another variable named X at the module global scope, the routine uses that variable instead. The program will compile and run, but it will behave differently than it would if DEBUG_MODE was True.

Private X As Integer

Private Sub MySub()
#If DEBUG_MODE Then    
    Dim X As Integer
#End If

Dim i As Integer    

    X = 1    
    For i = 1 To 10        
	X = X * i    
    Next i
End Sub

Debug code can also cause problems if it modifies nondebug variables. The following code compiles and runs but produces different results in debug and nondebug versions.

Private Sub MySub()
Dim i As Integer
Dim X As Integer    
    X = 1    
    For i = 1 To 10        
	X = X * i        
	
	#If DEBUG_MODE Then            
	    X = X + 1        
	#End If    
    Next i
End Sub

This example is somewhat contrived, but this problem can be subtle. For example, if the debugging code calls a subroutine, it may not be immediately apparent whether the routine modifies its parameters. If it does, the program’s debug and nondebug versions may be quite different.

Avoid all these issues by keep debug and nondebug code as separate as possible.

Figure 9.1  Program Bad9 is a crude text editor.

Self-Test

Program Bad9 violates some of the guidelines presented in this chapter. The program, shown in Figure 9.1, is a rather crude text editor. Select text in the text box. Then select a command in the command area and click the Apply button to perform the command. Click on checkboxes to change the selected text’s font styles.